IBIS Macromodel Task Group

Meeting date: 01 September 2020

Members (asterisk for those attending):
Achronix Semiconductor      * Hansel Dsilva
ANSYS:                      * Curtis Clark
                            * Wei-hsing Huang
Cadence Design Systems:       Ambrish Varma
                              Ken Willis
                            * Jared James
Google:                     * Zhiping Yang
Intel:                      * Michael Mirmak
Keysight Technologies:        Fangyi Rao
                            * Radek Biernacki
                              Ming Yan
                              Todd Bermensolo
                            * Rui Yang
Marvell                       Steve Parker
Mentor, A Siemens Business: * Arpad Muranyi
Micron Technology:          * Randy Wolff
                            * Justin Butterfield
SiSoft (Mathworks):         * Walter Katz
                              Mike LaBonte
Teraspeed Labs:             * Bob Ross
Zuken USA:                    Lance Wang

The meeting was led by Arpad Muranyi.  Curtis Clark took the minutes.

--------------------------------------------------------------------------------
Opens:

- Arpad asked if topic #7 (DDR5 DQ Write BCI protocol) could now be removed from
  the agenda.  Walter said it could and that he would reintroduce the topic
  later when he has more to discuss.

-------------
Review of ARs:

- Walter to prepare a draft of a BIRD relaxing the one-to-one pin to buffer
  requirement.
  - Done, sent to the ATM and Interconnect lists.
  
--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Arpad asked for any comments or corrections to the minutes of the August 25
meeting.  Michael moved to approve the minutes.  Randy seconded the motion.
There were no objections.

-------------
New Discussion:

Support for RDL in IBIS:
Walter shared the latest draft of BIRD_Dup_signal_name.  He said it is really
a clarification BIRD, and it would involve a small change in ibischk parser
logic.  He said it's a question of how the tool should interpret it when 2
[Pin]s use the same signal_name.

As a test, Walter had created an IBIS file with a [Pin] table containing two
pins that specified the same signal_name and different [Model] names.  He noted
that the ibischk parser issued no errors, but what should an EDA tool do in
this case?

Walter said the fact that two pins with the same signal_name could have
different model names was really confusing, and his new BIRD made it explicit
that this was an error.  Having resolved that issue, how does one interpret
2 pins having the same signal_name?  Walter said that 20 years ago there had
been a few IBIS models that used the same signal_name for every data line, but
that was not done in IBIS [Component]s anymore.  He noted that it makes more
sense to say such pins are connected, and that this is the approach they are
taking with EMD (BIRD202).

Arpad commented on the historical aspect.  He noted that up until recently,
EMD for example, signal_name had been meaningless in terms of the simulation.
We had only stated that it should be the data book signal name.  Only the
[Pin] name and [Model] name were actively affecting the simulation, and
signal_name was merely informative.  Now, with IBIS 7.0 Interconnect Model
syntax (BIRD189) and EMD, we are starting to give meaning to the signal_name
column, so we have to deal with it more rigorously.

Walter said there are components that have two clk pins, one on each side of
the component, that get routed to the chip from two sides but only go to one
buffer on the Si.  How do we want the model maker to represent that?  EMD is
a viable option, and we could force someone to make an EMD for that package.
However, a component might have a redistribution layer (RDL) that connects
multiple component pins to a single I/O buffer.  Do we want to consider a change
that would allow that to be handled within an .ibs file itself, as opposed to
having to use EMD?  This draft proposes one way to allow the .ibs file to
handle the additional wire-bond pads to multiple pins on the component, and to
then put the interconnect that connects them to one buffer inside the IBIS
[Component].  The proposal states that all signal pins with the same signal_name
shall have the same model name, and that all such pins shall connect to a single
instance of that buffer model.

Arpad said that we have to be very careful about the ways duplicate signal_names
would interact with new IBIS Interconnect package models and legacy package
modeling constructs.  When we say such duplicate signal_name pins are
"connected", at what interface?  Walter agreed and said he'd specified rules
depending on the package modeling type.  For new style interconnect modeling,
all such pins must appear as terminals in an interconnect model.  For [Package],
[Pin], and [Package Model]s that use [Number of sections] (i.e., uncoupled
lumped and distributed elements) independent parallel paths are defined from
each such pin to the single buffer.  Walter noted that this proposal is not
compatible with [Package Model]s using the coupled R, L, C matrices.

Walter said that this may not be the way to go.  It may be cleaner to make the
model maker put this into an EMD similar to an interposer model.  He said he was
proposing it to see what others thought about trying to handle this RDL special
case within the .ibs file.

Jared asked for an explanation of EMD.  Walter said that it is an enhanced
version of EBD (electronic board description).  EBD was originally designed for
DIMMs.  Instead of using a board file, it creates interconnects between the
connector pins of the DIMM and the pins of the IBIS components.  It was limited
to lumped or distributed R, L, C paths, but the routing could be point-to-point
or fly-by, etc.  The Interconnect task is now working on EMD (electronic module
description), which extends the concept to different substrates and packages and
better interconnect models.  So, now EMD could be used to represent the RDL's
connections from the wire bump pads to the buffer pads.  This new proposal might
be an easier way to represent that RDL within the .ibs file.

Arpad also recalled that EBD was originally conceived for DIMMs, which are
small PCBs with multiple chips on them.  The primary difference between EBD and
the legacy IBIS package modeling was that it supported non one-to-one
connections for signals between the external connector pins and the multiple
chips.  So, it doesn't matter whether it's a DIMM or a multi-chip module (MCM)
or stacked die component.  In an MCM the package is analogous to the DIMM PCB,
and the chips are analogous to the components on the DIMM PCB.

Jared said that his experience was in the die-side design, and his concern was
that when the chip designer does the extraction they go all the way to the wire
bond pad.  He feared the RDL would already been included in the SPICE circuit
used to generate the data in the IBIS [Model].  So, if we were to put RDL
interconnect in an IBIS package model, he was worried about double counting.
Randy said you have to consider whether the effect of that metal can be lumped
into C_comp, or if you want to break it out as a transmission line model.  This
could give you the flexibility to do either.  Walter said imagine you have a
stacked die situation on a dense memory module.  Maybe all the chips in the
stack are identical, but each has a different RDL.  It might be nice if the
IBIS model considered everything up to the bump pad.  Then you could put the
individual chips in different [Component]s whose package models contain the RDL
interconnect models.  Randy said we had lots of flexibility now, for example,
you could put the RDL in an interconnect model and handle the multi-die in
an EMD.

Bob said he thought we should defer this proposal for multiple pins with the
same signal_names.  He said it can get very complicated in certain areas, and
some of Walter's new rules would have to appear in other sections.  Arpad
suggested that one way to simplify this would be to say that the new proposal
is only available with newer interconnect syntax.  Randy agreed.

Bob said it's possible we can achieve this using only the new interconnect
syntax.  He noted, however, that one point of confusion would be the ambiguity
of multiple pins connected to the same buffer instance.  If two pins specify
the same signal_name and model, how do you designate which buffer is connected?
In interconnect syntax you'd have two buffers (conceptually), but only one would
be connected?  Arpad agreed that this could cause confusion, as a tool would
look at the [Pin List] and assume each pin corresponded to a buffer.  It
wouldn't necessarily look at the interconnect model to see how the connections
are made.  Walter proposed a few possible variations, such as specifying an
NA or NC model for the additional pins used in the interconnect model, so it was
clear those pins couldn't be imported directly.  Radek and Arpad thought this
was questionable and confusing, and they suggested we might want to invent an
RDL Pin keyword or a reserved Model name instead.

Walter said he had just proposed the idea to gather suggestions and feedback.
He said he would think about it some more.  Walter moved to table the topic for
now.  Jared seconded.  There were no objections.

Supporting PI modeling/simulation in IBIS:
Zhiping shared some thoughts from the IBIS Summit with the IEEE EMC+SIPI
symposium.  He said he thought some of the presentations contained good topics
that could become BIRDs.  He noted that a presentation from Intel on a
standardized PI modeling concept even contained a rough draft of a BIRD.
Randy suggested that it might be interesting to review the Intel presentation
here in ATM.  He asked if Michael could invite the presenter or possibly present
it in ATM himself.  Michael said he could look into it.

Walter moved to cancel next week's scheduled meeting and pick up this topic at
the following meeting.  Randy seconded.  There were no objections.  There will
be no meeting on September 8th.

- Walter: Motion to adjourn.
- Randy: Second.
- Arpad: Thank you all for joining.

-------------
Next meeting: 15 September 2020 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
